Suppose  two  meteorologists  make  predictions  about 
the  weather  for  a  particular  Saturday.  Mr.  Gray  says 
there  is  a  50  percent  chance  of  rain,  and  Mr.  Blue 
says  there  is  a  25  percent  chance  of  rain.  On  the  Sat¬ 
urday  in  question,  it  does  indeed  rain. 

Which  one  was  right:  the  one  who  predicted  a  50  percent 
chance  of  rain  or  the  one  who  predicted  half  that  percent¬ 
age?  Were  they  both  right?  Was  Gray  twice  as  right  as  Blue? 
Can  we  say  that  one  prediction  was  more  reliable,  more  use¬ 
ful,  or  more  accurate  than  the  other?  I  don't  think  we  can. 

Yes,  But  Should  We  Take  the  Umbrella? 

Have  you  ever  stopped  to  wonder  what  it  really  means  when 
we  say  there  is  a  50  percent  chance  of  rain?  Does  it  mean 
that  on  100  Saturdays  with  these  initial  conditions,  50  will 
get  rained  on?  Or  is  the  forecaster  simply  50  percent  sure  it 
will  rain  this  Saturday,  whatever  that  means?  Is  there  a  differ¬ 
ence?  And  does  either  interpretation  of  the  prediction  affect 
our  behavior?  Should  we  take  half  an  umbrella  when  there 
is  a  50  percent  chance  of  rain?  Do  we  develop  half  a  backup 
plan?  Or  simply  go  to  the  museum  instead  of  having  a  picnic 
on  half  such  days?  And  what  if  we  pick  the  wrong  half? 

More  to  the  point,  if  a  25  percent  prediction  of  rain  and  a  50 
percent  prediction  of  rain  can  both  point  to  a  rain  event  and 
say,  “See,  I  told  you  it  might  rain!"  (or  point  to  a  non-rainy 
day  and  say  much  the  same  thing),  what  value  is  there  in  the 
prediction?  How  does  this  prediction  help  with  our  planning 
or  execution? 

There  Are  No  Facts  About  the  Future 

Jeff  Wacker,  a  fellow  at  the  EDS  Corporation,  once  explained 
to  me:  "There  are  no  facts  about  the  future."  I  thought  that 
was  an  interesting  observation,  particularly  coming  from 
someone  whose  job  title  is  "futurist."  It  also  struck  me  as 
particularly  insightful  and— most  important— completely 
true.  It  also  struck  me  that  being  a  futurist  could  be  either 
really  fun  and  easy,  or  really  frustrating  and  hard.  It's  prob¬ 
ably  both. 

The  Zero  Future  Facts  Principle  is  illustrated  in  Figure  1.  For 
simplicity,  the  number  of  facts  in  the  universe  is  represented 
as  increasing  linearly,  but  this  need  not  be  the  case  and  is 
not  germane  to  this  discussion.  The  only  important  fact  is 
that  beyond  the  Now  Point,  there  are  no  facts.  In  the  future, 
there  are  only  conjectures,  estimates,  guesses,  and  predic¬ 
tions.  We  can  assign  a  percentage  to  our  prediction  (a  50 
percent  chance  of  rain,  for  example),  but  that  does  not  make 
it  a  fact.  The  only  facts  well  ever  encounter  are  about  what 
has  happened  or  what  is  happening.  There  are  no  facts  about 
what  will  happen. 
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This  principle  has  serious  implications  for  program  manag¬ 
ers,  as  research  by  the  Standish  Group  demonstrates.  Per¬ 
forming  research  on  project  success  and  failure  since  1985, 
Standish  Group  reports  bluntly  state  that  estimates  come  in 
two  categories:  lucky  or  lousy.  According  to  their  research, 
"there  is  no  such  thing  as  a  reliable  estimate.  Learning  to 
work  better  with  poor  estimates  rather  than  developing  bet¬ 
ter  estimating  techniques  is  crucial."  One  more  time:  there 
are  no  facts  about  the  future. 

Yet  we  make  programmatic  estimates  and  predictions  all 
the  time  and  somehow  end  up  treating  these  things  as  facts. 
As  Dr.  Roger  Atkinson  poignantly  observed,  our  projections 
about  time  and  costs  are  "at  best  only  guesses,  calculated  at 
a  time  when  least  is  known  about  the  project."  We  should 
be  mindful  of  this  when  looking  at  cost  estimates  for  a  10- 
year  project  or  statements  of  operational  requirements  for 
the  year  2020. 


Figure  1.  The  Zero  Future  Facts  Principle 


Reflective  Practice  and  Practical  Reality 

In  order  to  help  project  leaders  deal  with  these  future  non¬ 
facts,  I  have  assembled  a  handful  of  charts  and  equations 
that  are  presented  here  for  your  consideration.  Unlike  dubi¬ 
ous  weather  forecasts  and  cost  estimates,  the  figures  and 
formulas  that  follow  are  emphatically  not  based  on  quantita¬ 
tive  research  data.  Instead,  they  are  the  result  of  a  "reflec¬ 
tive  practice"  methodology,  as  described  by  Donald  Schon's 
book  The  Reflective  Practitioner. 

The  discipline  of  reflective  practice  has  a  much  stronger 
basis  in  practical  reality  than  the  so-called  scientific  at¬ 
tempts  to  predict  with  probabilities,  which  tend  to  be  aca¬ 
demic  and  idealized.  In  contrast,  reflective  practice  primarily 
relies  on  experienced  intuition  and  tacit  knowledge— what 
the  late  Air  Force  Col.  John  Boyd,  military  strategist,  called 
"fingerspitzengefuhl."  My  introduction  of  this  foreign  word, 
combined  with  a  reference  to  a  dead  authority  figure,  is  done 
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to  enhance  the  perception  of  the  methodology's  legitimacy 
among  those  who  value  the  trappings  of  scientific  thought. 
Greek  letters,  Latin  phrases,  square  brackets,  mathematical 
terms  such  as  “absolute  value,"  and  subscripts  will  be  used 
in  subsequent  paragraphs  for  the  same  reason. 

Since  most  system  development  efforts  begin  with  require¬ 
ments,  that's  where  we'll  start  too.  In  many  projects,  a  dedi¬ 
cated  effort  is  made  to  ensure  the  requirements  remain  stable. 
I  have  even  heard  talk  of  freezing  requirements  at  the  time 
the  contract  is  awarded.  However,  requirement  stability  is  not 
always  desirable  or  beneficial.  Over  time,  the  value  and  rel¬ 
evance  of  a  requirement  degrades,  either  because  of  advances 
in  technology  that  render  the  required  capability  technically 
obsolete  or  changes  in  the  threat  environment  that  render  the 
requirement  operationally  irrelevant.  Or  maybe  the  require¬ 
ment  simply  wasn't  very  good  to  begin  with. 

Increasing  the  project's  duration 
increases  its  exposure  to  any 


being  considered.  The  requirements  for  a  piece  of  electronic 
equipment,  for  example,  will  likely  become  stupid  at  a  faster 
rate  than  the  requirements  for  a  suspension  bridge.  It  is  also 
worth  noting  that  these  two  laws  apply  directly  to  individual 
requirements  and  apply  exponentially  to  documents  con¬ 
taining  multiple  requirements. 

Clearly,  these  laws  illustrate  the  importance  of  stable  require¬ 
ments  over  short  timelines  and  flexible  requirements  over 
long  timelines.  Some  might  even  suggest  they  illustrate  the 
importance  of  short  timelines,  a  la  mode,  a  priori ,  and  sine  qua 
non  [see  earlier  statement  about  the  use  of  foreign  phrases]. 

More  Laws  and  Theorems 

Another  way  of  depicting  the  relationship  between  require¬ 
ment  flux  and  time  is  with  the  Requirement  Shelf-Life  Ratio 
Theorem,  which  states,  “The  amount  of  time  spent  devel¬ 
oping  a  system  (Td)  should  be  shorter  than  the  mean-time 
between  legitimate  requirements  change  (Trc)."  Math¬ 
ematically,  this  is  represented  thus:  Td  <  Trc.  [Note  the  use 
of  subscripts,  which  is  a  universally  acknowledged  sign  of 
scientifically.] 


number  of  change  events,  and 
the  impact  on  the  project  is 
exponentially  proportional  to  the 
sum  of  all  the  delays. 

Thus,  I  developed  the  Law  of  Requirement  Stability,  which 
states,  “The  viability  of  a  stable  requirement  drops  off  at  an 
exponential  rate  over  time."  This  assumes  the  initial  require¬ 
ment  was  good.  In  the  event  of  a  poor  initial  requirement, 
the  value  drops  off  much  faster. 

Former  Secretary  of  Defense  Gordon  England  expressed  his 
support  for  this  law  in  his  June  3,  2009,  testimony  to  the 
House  Armed  Services  Committee's  Defense  Acquisition 
Reform  Panel.  England  said,  “Over  time,  they  [requirements] 
actually  do  have  to  change.  ...  It's  a  reality  of  design  and 
production  and  things.  You  want  them  to  change. ...  It's  not 
all  bad  to  change  requirements  as  a  program  proceeds."  It 
appears  requirements  do  indeed  have  a  limited  shelf  life. 

A  corollary  to  this  law  is  the  Law  of  Stupid  Stability,  which 
states,  "The  stupidity  of  making  a  requirement  stable  is  di¬ 
rectly  proportional  to  the  timeframe  over  which  the  stability 
is  enforced."  According  to  the  law,  as  a  requirement  resists 
changes  over  a  longer  period  of  time,  the  likelihood  of  it  being 
stupid  is  increased.  [Technical  Note:  The  term  "stupid"  is  a 
formal  engineering  term  that  refers  to  requirements  pursued 
despite  being  technically  obsolete,  operationally  irrelevant, 
or  both].  Obviously,  the  timeframes  in  question  for  these 
two  laws  will  vary  depending  on  the  type  of  technology 


This  theorem  explains  that  if  the  amount  of  time  spent  devel¬ 
oping  a  system  exceeds  the  sum  of  the  requirements'  shelf- 
life,  the  resulting  system  will  be  operationally  irrelevant  and/ 
or  technically  obsolete  (i.e.,  "stupid")  when  delivered.  As 
with  the  earlier  laws,  the  Requirement  Shelf-Life  Ratio  Theo¬ 
rem  suggests  that  short  timelines  are  much  to  be  desired. 

Once  the  requirements  are  established  and  the  develop¬ 
ment  work  begins,  project  leaders  are  often  faced  with  op¬ 
portunities  to  delay  decisions  and  push  significant  events  to 
the  right.  The  previous  laws  and  theorems  notwithstanding, 
there  is  a  widespread  belief  that  schedule  extensions  im¬ 
prove  the  project's  outcome.  Our  research  shows  that  such 
extensions  should  be  avoided  at  all  costs  because  of  the 
Law  of  Increasing  Impact,  which  states,  "The  impact  of  a 
delay  increases  exponentially  with  the  length  of  the  sum  of 
the  delays." 
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Figure  3.  The  Law  of  Error  Propagation 
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Let's  take  a  closer  look  at  why  this 
law  is  true.  Over  a  given  amount  of 
time,  projects  are  exposed  to  a  cer¬ 
tain  amount  of  change.  Over  a  lon¬ 
ger  timeframe,  they  are  exposed  to 
a  greater  quantity  of  change  events. 

These  change  events  increase  the  risk 
of  technological  obsolescence;  bud¬ 
get  instability;  operational  irrelevance; 
personnel  transfer  (which  causes  a 
loss  of  learning,  accountability,  and 
consistent  leadership  vision  and  sup¬ 
port);  and  non-compliance  with  new 
regulatory  requirements.  Increasing 
the  project's  duration  increases  its 
exposure  to  any  number  of  change 
events,  and  the  impact  on  the  project 
is  exponentially  proportional  to  the  sum  of  all  the  delays. 

Close  study  of  the  Law  of  Increasing  Impact  intuitively  re¬ 
veals  the  Recursive  Delay  Self-Propagation  Theorem,  which 
states,  “The  length  of  a  delay  increases  with  the  length  of  the 
delay.''  That  is,  any  increase  in  a  project's  development  sched¬ 
ule  will  cause  an  additional  increase  to  the  project's  devel¬ 
opment  schedule.  Mathematically,  this  can  be  expressed  as 

D=  D  ■+■  sin  a  sin  0  +  2  sin  ^  (a  +  fi)  cos^  (a  -  0)  + 

„  \  /  nwx  ,  t  j 

+2_ln  +6nSlTl— J 

or  more  simply,  as  D  =  D  +  n,  where  D  is  the  delay  and  n  is 
some  number.  The  proof  is  left  as  an  exercise  for  the  reader. 

A  concrete  example  may  shed  further  light  on  this  principle. 
Consider  that  a  sufficiently  long  delay  in  a  project  leads  to 
instability  among  project  personnel  (resulting  from  retire¬ 
ments,  promotions,  transfers,  etc.),  which  leads  to  additional 
delays  as  the  new  personnel  are  hired,  trained,  and  brought 
up  to  speed  on  the  project.  Each  new  person  introduces  ad¬ 
ditional  change,  which  exacerbates  the  whole  situation  and 
causes  more  delay,  making  progress  impossible.  This  prin¬ 
ciple  is  also  known  as  Zeno's  Donut  of  Conundrum,  and  is 
illustrated  in  Figure  2.  [NOTE:  Zeno's  Donut  of  Conundrum 
is  named  after  my  uncle  Zeno,  and  is  not  to  be  confused  with 
Zeno's  Paradox  of  Motion  from  Greek  philosophy ...  but  now 
that  I  think  about  it,  they're  quite  similar.] 

No  Certainty  but  Uncertainty 

Let  us  now  return  to  the  central  theme  of  uncertainty.  Be¬ 
cause  there  are  no  facts  about  the  future,  our  estimates 
of  future  values  are  sometimes  incorrect.  For  the  sake  of 
appearing  scientific,  we  use  the  Greek  letter  delta  (A)  to 
represent  the  absolute  value  of  the  difference  between  a 
predicted  value  and  the  actual  value.  As  an  error  propagates 
over  time,  the  value  of  A  increases  according  to  the  Law  of 
Error  Propagation  (see  Figure  3),  which  states,  “The  absolute 


value  of  the  A  between  an  actual  value  and  an  erroneously 
predicted  value  increases  in  direct  proportion  to  the  time 
over  which  the  error  is  propagated."  So  given  sufficient  time, 
small  errors  become  big  errors.  As  we  see  in  Figure  3,  A2, 
which  occurs  later  in  time,  is  much  larger  than  AT 

The  Case  for  Short  Timelines 

Taken  together,  all  of  these  laws,  theorems,  and  principles 
make  a  strong  case  for  using  short  timelines  when  devel¬ 
oping  a  new  system.  This  perspective  is  emphatically  sup¬ 
ported  by  countless  Government  Accountability  Office  re¬ 
ports,  one  of  which  explained:  “A  hallmark  of  an  executable 
program  with  a  sound  business  case  is  short  development 
cycle  times"  (Report  on  Selected  Weapon  Systems,  GAO, 
2008,  emphasis  added). 

In  much  the  same  spirit,  The  Standish  Group  explained  in  a 
1999  report  that  “we  have  long  been  convinced  that  shorter 
time  frames  ...  increase  the  success  rate."  In  their  February 
2008  newsletter,  The  Standish  Group  was  more  emphatic, 
writing  that  “with  projects,  slow  kills;  speed  increases  suc¬ 
cess."  A  particularly  fierce  report  by  The  Standish  Group 
observes  that  “time  is  the  absolute  enemy  of  all  projects." 
Time  therefore  joins  Al  Qaeda  and  the  Taliban  in  the  latest 
Axis  of  Evil. 

At  this  point,  we  briefly  deviate  from  our  preferred  reflec¬ 
tive  practice  method  and  introduce  some  actual  research 
data,  compliments  of  the  aforementioned  Standish  Group. 
Some  readers  may  wish  to  skip  this  section,  and  we  com¬ 
pletely  understand.  In  our  own  defense,  we  should  point 
out  that  these  are  someone  else's  data,  not  our  own  origi¬ 
nal  research.  We  did  not  collect  it  and  are  merely  reflecting 
on  it.  Also,  note  that  the  percentages  in  Figure  4  are  mea¬ 
surements  from  the  past,  not  predictions  about  the  future. 

The  figure,  Project  Duration,  Size  Affect  Success,  presents 
five  years'  worth  of  data  gathered  by  The  Standish  Group 
from  IT  projects.  It  shows  the  correlation  between  project 
duration,  team  size,  and  project  success. 
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Project  Size_ People (mos.) Rate 

<  $750K 

6 
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$750  -  $1.5M 

12 
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$1.5M  -  $3M 

25 

12 

25% 

$3M  -  $6M 

40 

18 

15% 

$6M  -  $10M 

250+ 

24+ 

8% 

Over  $10M 

500+ 

36+ 

0% 

The  results  are  striking,  even  if  we  chose  to  disbelieve  the 
measured  success  rate  for  the  largest  projects.  (Really?  None 
of  them  succeeded?  OK,  I  guess  that's  not  too  surprising.) 
The  overall  trend  clearly  shows  that  success  and  duration 
are  inversely  proportional,  historically  speaking.  As  reflective 
practitioners,  what,  then,  should  we  make  of  this  in  terms  of 
practical,  actionable  conclusions?  Perhaps  the  most  reason¬ 
able  conclusion  is  that  when  launching  a  new  project,  we 
should  establish  the  shortest  possible  schedule  and  ensure 
that  schedule  slips  are  treated  as  a  measure  of  last  resort. 
We  should  never  expect  schedule  delays  to  help  ensure 
project  success. 

This  means  project  leaders  should  be  willing  to  descope 
the  project  before  accepting  a  schedule  delay  because  it  is 
generally  better  to  deliver  something  rather  than  nothing, 
and  to  succeed  a  little  rather  than  fail  a  lot.  Similarly,  the 
evil  practice  of  taking  money  from  a  project  in  the  current 
year  and  repaying  it  in  a  future  year  should  be  avoided  at  all 
costs.  Such  a  tactic  merely  pushes  the  work  out  to  a  future 
year,  which  causes  a  ripple  of  increasing  delays,  and  that's 
not  good. 

In  order  to  help  keep  the  timeline  sufficiently  short,  the  or¬ 
ganization  should  probably  use  a  small  team  and  provide  a 
small  budget,  per  Figure  4.  This  does  not  guarantee  success, 
but  it  seems  to  increase  the  odds  (whatever  that  means). 
Such  a  restrained,  disciplined  approach  has  the  desirable 
effect  of  enabling  a  larger  number  of  small  projects  across 
the  enterprise,  each  of  which  has  a  greater  likelihood  of 
success, based  on  historical  trends  (if  we  may  be  allowed  to 
make  a  prediction  about  the  future).  Yes,  it  is  harder  to  man¬ 
age  and  deconflict  a  portfolio  of  many  small  projects,  but 
isn't  it  more  fun  to  have  projects  that  succeed?  And  making 
life  easier  for  management  isn't  really  the  point  now,  is  it? 

In  conclusion,  the  verdict  is  in.  Long  development  timelines 
are  contra  bonos  mores  and  cogito  ergo  sum.  If  we  want  to  suc¬ 
cessfully  deliver  our  projects,  we'd  better  move  fast.  Quod 
erat  demonstrandum. 


The  author  welcomes  comments  and  questions  and  can  be 
contacted  at  daniel.ward@pentagon.af.mil. 
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